Access Control Explained: Models, Policies & Best Practices

Control who can do what, where, and when. This guide covers access control models, design patterns, real-world examples, code snippets, testing, and a practical lab.

1. Introduction to Access Control

Access control is the set of technical and procedural controls that determines who (or what) — a user, system, or process — is allowed to access resources (files, systems, APIs, physical rooms) and what actions they can take.

At its core it answers three questions: Who?, What?, and Under what conditions?

💡 Pro Tip: Treat access control as a lifecycle: design → enforce → monitor → review → adjust.

2. History & Evolution of Access Control

Access control concepts evolved from simple file permissions on early UNIX systems to complex policy engines integrated with identity platforms and cloud providers.

1970s–1980s: DAC on UNIX (owner-based file permissions).
1980s–1990s: MAC introduced for classified systems (military).
2000s: Role-Based Access Control (RBAC) standardized and widely adopted.
2010s–present: Attribute-Based Access Control (ABAC), Policy-Based Access Control (PBAC), and cloud-native IAM rise.

3. Why Access Control Matters

Correct access control prevents unauthorized data access, limits lateral movement in breaches, supports least privilege, and helps satisfy compliance (GDPR, HIPAA, PCI-DSS).

Poorly designed access control is a frequent cause of breaches and compliance failures.

⚠️ Warning: Over-permissive access (excessive privileges) is one of the top risks in enterprise environments.

4. Access Control Fundamentals

Key concepts:

Subjects: Actors requesting access (users, services, devices).
Objects: Resources being accessed (files, databases, APIs).
Operations: Actions allowed (read, write, execute, delete).
Policies: Rules that permit or deny (allow/deny).
Enforcement: Gateways that enforce policies (PDP/PEP paradigm).

5. Types of Access Control (Overview)

Discretionary Access Control (DAC)
Mandatory Access Control (MAC)
Role-Based Access Control (RBAC)
Attribute-Based (ABAC) & Policy-Based (PBAC)
Rule-based & Contextual Control (time, location, device posture)

6. Discretionary Access Control (DAC)

In DAC, resource owners decide who gets access. This is the model used by UNIX file permissions and Windows ACLs.

UNIX example


# File permissions: rwxr-x---  owner: alice  group: devs
-rwxr-x--- 1 alice devs 4096 Jun 10 12:00 report.txt

# Change owner and permissions
chown alice:devs report.txt
chmod 750 report.txt

**Pros:** Simple, flexible.
**Cons:** Owner errors, difficult to scale, can lead to privilege sprawl.

7. Mandatory Access Control (MAC)

MAC enforces access decisions centrally based on labels (e.g., classification levels). Users cannot change labels — policies are mandatory.

Example: SELinux / AppArmor

SELinux applies policies that confine processes based on labels (e.g., httpd_t cannot read /etc/shadow).


# Check SELinux mode
getenforce

# See SELinux context of a file
ls -Z /etc/shadow

**Pros:** Strongest control for high-assurance environments.
**Cons:** Complex policy design and operational overhead.

8. Role-Based Access Control (RBAC)

RBAC assigns permissions to roles; users are assigned roles. It scales well for enterprise orgs and is widely used in cloud IAM and AD.

RBAC model components

Users — individuals or service accounts
Roles — named collections of permissions
Permissions — allowed actions on resources
Sessions — runtime instantiation of user-role mappings

Example: SQL GRANTs using RBAC pattern


-- create role and grant permissions
CREATE ROLE analytics;
GRANT SELECT ON sales.* TO analytics;

-- assign user to role
GRANT analytics TO user_alice;

💡 Pro Tip: Use role hierarchies (senior_role inherits junior_role) to reduce administration overhead.

**Pros:** Scalable, auditable.
**Cons:** Role explosion if not designed carefully.

9. Attribute-Based Access Control (ABAC) & Policy-Based Access Control (PBAC)

ABAC evaluates attributes (user, resource, environment) against policies. PBAC is a broader term emphasizing policy engines and fine-grained decisions — often implemented using XACML, Open Policy Agent (OPA), or cloud policy engines.

ABAC decision example (pseudo)


# Pseudocode: allow if
if user.department == resource.department and user.clearance >= resource.classification and request.time within business_hours:
    allow
else:
    deny

OPA (Open Policy Agent) example (rego)


package example.authz

default allow = false

allow {
  input.user.department == input.resource.department
  input.user.clearance >= input.resource.classification
}

**Pros:** Very flexible and context-aware.
**Cons:** Policy complexity, requires robust attribute sources (IDPs, CMDBs).

10. Physical vs Logical Access Control

Access control spans physical (badges, locks) and logical (accounts, tokens). Both must be managed — poor physical security can undermine strong logical controls and vice versa.

Logical: LDAP, Active Directory, cloud IAM, OAuth scopes, API keys
Physical: Badge systems, locks, CCTV, mantraps

11. Access Control Policies & Rule Design

Policy design best practices:

Least privilege: Grant minimum permissions needed.
Separation of duties (SoD): Prevent conflicts of interest (e.g., developer ≠ deployer).
Default deny: Deny unless explicitly allowed.
Just-in-time (JIT) & ephemeral access: Temporary elevation for tasks.
Attribute validation: Ensure attributes are trustworthy (signed tokens, verified sources).

Policy enforcement architecture

Modern designs use a Policy Decision Point (PDP) and Policy Enforcement Point (PEP):

PDP: evaluates policy and returns decision (allow/deny/obligations)
PEP: enforces decision at the resource boundary (API gateway, app)

12. Access Control in Cloud Environments

Cloud IAM models combine RBAC and ABAC concepts. Identity is the new perimeter — tightly integrate identity providers (IdP), MFA, and device posture.

AWS IAM policy example (JSON)


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::example-bucket/*"],
      "Condition": {
        "StringEquals": {"aws:PrincipalTag/Department": "Finance"}
      }
    }
  ]
}

**Cloud tips:** Tag resources, use least privilege, enable MFA & role-based sessions, audit logs (CloudTrail, Cloud Audit).

13. Common Access Control Vulnerabilities

Excessive permissions (over-privilege)
Poorly protected admin accounts (no MFA)
Broken access control bugs in apps (Insecure Direct Object Reference — IDOR)
Hard-coded credentials or long-lived API keys
Weak attribute sources (untrusted claims in JWTs)

⚠️ Warning: IDOR vulnerabilities are often exploitable with simple URL manipulation — validate authorization on the server side for each request.

14. Real-World Breaches Caused by Poor Access Control

Examples (summaries):

Misconfigured S3 buckets: Publicly readable data due to overly-permissive policies.
Exposed admin panels: Accessible without MFA or IP restrictions leading to takeover.
Excessive cloud IAM roles: Service account with broad permissions abused in an attack.

Learning: routine entitlement reviews and automation (e.g., access reviews) reduce risk.

15. Implementing Access Control — Code & Config Examples

15.1 Linux file perms (practical)


# Create group and user, set group ownership and perms
sudo groupadd finance
sudo useradd -G finance bob
sudo chown :finance /srv/finance
sudo chmod 770 /srv/finance

15.2 SQL example: Row-level security (PostgreSQL)


-- Enable row-level security
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

-- Create policy: users can see invoices for their tenant
CREATE POLICY tenant_policy ON invoices
  USING (tenant_id = current_setting('my.tenant_id')::int);

15.3 OAuth2 / JWT scope example (API)


# JWT payload sample
{
  "sub": "user123",
  "scope": "orders:read orders:write",
  "exp": 1710000000
}

# API checks token and scopes before allowing endpoint access

15.4 Open Policy Agent (OPA) integration (example)


# Application sends input to OPA
input = {
  "user": {"id":"alice","dept":"sales"},
  "resource": {"owner":"sales", "type":"report"}
}

# OPA returns allow=true/false; enforce in app

💡 Pro Tip: Centralize policy logic (PDP) using OPA or a cloud policy engine — keep enforcement points (PEP) thin.

16. Tools & Frameworks for Access Control

Identity Providers (IdP): Okta, Azure AD, Ping Identity
Policy Engines: Open Policy Agent (OPA), XACML engines
Cloud IAM: AWS IAM, Azure RBAC, GCP IAM
Privilege Management: CyberArk, BeyondTrust
Directory Services: Active Directory, LDAP
Secrets Management: HashiCorp Vault, AWS Secrets Manager

17. Testing & Auditing Access Controls

Testing and auditing are essential. Key activities:

Automated entitlement reviews: Quarterly or after changes.
Pentest for access control: Check for IDOR, elevation-of-privilege, broken auth flows.
Policy simulation: Test ABAC/OPA policies with sample inputs before rollout.
Log & audit: Collect auth/access events (who, what, when, where) and retain per compliance.

Audit sample: what to log

User identifier
Resource identifier
Action attempted
Decision (allow/deny) and policy reference
Timestamp, source IP, device posture

18. Conclusion, Lab Exercises & FAQs

18.1 Final recommendations

Adopt least privilege and default deny everywhere.
Centralize policy decisions with a PDP (OPA, cloud IAM).
Use RBAC for coarse entitlement, ABAC/PBAC for fine-grained controls.
Automate provisioning, deprovisioning, and access reviews.
Monitor, log, and test regularly.

18.2 Hands-on Lab: From UNIX perms to ABAC

Objective: implement basic RBAC on Linux, add a temporary JIT role, and test a simple OPA ABAC decision.

Step A — Linux RBAC (groups)


# Create groups and users
sudo groupadd finance
sudo useradd -m -G finance alice
sudo useradd -m -G dev bob

# Secure a directory for finance
sudo mkdir /srv/finance
sudo chown :finance /srv/finance
sudo chmod 770 /srv/finance

# Verify
ls -ld /srv/finance

Step B — Just-in-Time (JIT) tmp elevation (example)


# On a central workflow, request temporary sudo rights for 2 hours via approval process (tool example: AWS IAM role assumption or Azure PIM)
# Example (AWS): sts assume-role with DurationSeconds=7200

Step C — Simple OPA policy test


# Run OPA locally and evaluate a policy with input.json
# 1) Save policy.rego (see earlier ABAC example)
# 2) Save input.json:
{
  "user": {"dept":"sales","clearance":2},
  "resource": {"department":"sales","classification":1}
}

# 3) Evaluate
opa eval -i input.json "data.example.authz.allow"

18.3 SEO-Friendly FAQs (for featured snippets)

What is access control?
Access control is the set of policies and mechanisms that determine who or what can access resources and what actions they can perform.
What is the difference between RBAC and ABAC?
RBAC assigns permissions to roles, then users to roles. ABAC evaluates attributes (user, resource, environment) against policies for fine-grained decisions.
When should I use MAC?
Use Mandatory Access Control (MAC) in high-assurance environments (military, government) where strict, centrally-enforced labels are required.
How often should I review access permissions?
At minimum quarterly, but more frequently for highly privileged accounts or after organizational changes.
What is least privilege?
A principle that entities should receive the minimum level of access needed to perform their tasks.

Discuss your current access control challenges in the comments — I can craft a tailored checklist or help design a role matrix for your org.

Learn Cyber Security